Actions: Add new models for external actions/workflows - #22263

This magic number approach does not sound right to me. But I lack sufficient contextual knowledge here to suggest anything.

It is just a GUID without dashes. On one hand, especially because it becomes visible in web ui alert, it could be something human readable. On the other hand something very short such as reusable_workflow may collide with a folder in the repository. So something like downloaded_external_workflows_and_actions may work. I went with a unique GUID, but I'm open for discussions.

Quick check: for tuples in externalCompositeActionDataModel is it true that there is at most one such tuple for each local_path? I.e. does the local_path uniquely determine the rest of the values? Because otherwise this looks like a massive performance pitfall, since this joins with any Locationwith a matchinggetFile`.

local_path is not unique: the producer intentionally lets requested refs with identical content share one materialized file while retaining separate provenance rows.
However, I asked AI to check the generated evaluator plan. The current predicate scans the model rows first and then uses keyed joins through relative path, file, location, and the action AST; it does not start by enumerating every Location. I also tested a path-bound bindingset/inline_late helper, but that changed the plan to an AST-to-model Cartesian product, increased joined tuples, and showed no runtime improvement.

Same question applies here as the pattern is the same.

I tested this on the Grafana Actions database. All eight reusable-workflow model rows resolved to extracted workflow files, with each local_path matching the AST file’s relative path. The current plan scans externalReusableWorkflowDataModel first and uses keyed joins through file, location, and ReusableWorkflowImpl.